For many years, Ethernet has been used as a LAN (Local Area Network) technology, and enterprises have managed these networks with the use of Internet protocols such as Simple Network Management Protocol (SNMP), ICMP Echo (or IP Ping), IP Traceroute, and Cisco Unidirectional Link Detection Protocol (UDLD). EOAM (Ethernet Operations Administration and Maintenance) is a protocol for installing, monitoring, and troubleshooting MANs (Metropolitan Area Network) and WANs (Wide Area network). The use of Ethernet as a networking technology has created the need for a new set of OAM protocols since there are now large and complex networks with a wide user base that involves different operators providing end-to-end services.
The IETF (Internet Engineering Task Force) develops and promotes Internet standards. The One-way Active Measurement Protocol [RFC4656] (OWAMP) provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements.
Two-Way Active Measurement Protocol (TWAMP) provides a standards-based method for measuring the round-trip IP performance (packet loss, delay and jitter) between two devices. TWAMP uses the methodology and architecture of One-Way Active Measurement Protocol (OWAMP) to define a way to measure two-way or round-trip metrics.
There are four logical entities in TWAMP: the Control-Client, the Session-Sender, the Server, and the Session-Reflector. The Control-Client and Session-Sender are typically implemented in one physical device (the “Client”) and the Server and Session-Reflector in a second physical device (the “Server”) with which the two-way measurements are being performed.
The Control-Client and Server establish a TCP (Transmission Control Protocol) connection and exchange TWAMP-Control messages over this connection. When the Control-Client wants to start testing, the Client communicates the test parameters to the Server. If the Server agrees to conduct the described tests, the test begins as soon as the Client sends a Start-Sessions message. As part of a test, the Session-Sender sends a stream of UDP-based (User Datagram Protocol) test packets to the Session-Reflector, and the Session-Reflector responds to each received packet with a response UDP-based test packet. When the Session-Sender receives the response packets from the Session-Reflector, the information is used to calculate two-way delay, packet loss, and packet delay variation between the two devices.
In TWAMP Light, (part of RFC 5357) the roles of Control-Client, Server, and Session-Sender are implemented in one host referred to as the Controller, and the role of Session-Reflector is implemented in another host referred to as the Responder.
TWAMP Light provides a simple architecture for Responders where their role is to simply act as light test points in the network. The Controller establishes the test session with the Server through non-standard means. After the session is established, the Controller transmits test packets to the Responder. The Responder follows the Session-Reflector behavior of TWAMP with the following exceptions.
In the case of TWAMP Light, the Session-Reflector does not necessarily have knowledge of the session state. If the Session-Reflector does not have knowledge of the session state, then the Session-Reflector must copy the Sequence Number of the received packet to the Sequence Number field of the reflected packet. The Controller receives the reflected test packets and collects two-way metrics. This architecture allows for collection of two-way metrics.
TWAMP Light eliminates the need for the TWAMP-Control protocol, and assumes that the Session-Reflector is configured and communicates its configuration with the Server through non-standard means. The Session-Reflector simply reflects the incoming packets back to the Controller while copying the necessary information and generating sequence number and timestamp values. TWAMP Light introduces some additional security considerations. The non-standard means to control the responder and establish test sessions offers the following features. The non-standard responder control protocol has an authenticated mode of operation. The responder is configurable to accept only authenticated control sessions. The non-standard responder control protocol has a means to activate the authenticated and encrypted modes of the TWAMP-Test protocol. When the TWAMP Light test sessions operate in authenticated or encrypted mode, the Session-Reflector must have some mechanism for generating keys (because the TWAMP-Control protocol normally plays a role in this process, but is not present here).